The Metro Ethernet Forum (MEF, metroethernetforum.org) is an alliance defining technical specifications and implementation agreements to promote interoperability and deployment of Carrier Ethernet worldwide. Exemplary technical specifications include MEF 6.1, Ethernet Services Definitions, Phase 2, April 2008; MEF 10.2, Ethernet Services Attributes Phase 2, October 2009; and MEF 26.1, External Network Network Interface (ENNI)—Phase 2, January 2012; the contents of each is incorporated by reference herein. Ethernet Tree (E-Tree) is a MEF service construct (defined in MEF 6.1) using a Rooted-Multipoint Ethernet Virtual Circuit type (defined in MEF 10.2). An E-Tree service, associating Root (R) and Leaf (L) User-Network Interfaces (UNIs) (defined in MEF 10.2), can be supported across a single Carrier Ethernet Network (CEN) [reference: MEF 6.1] or multiple CENs [reference: MEF 26.1]. The key behavior of the E-Tree service is to allow an ingress frame at a Root UNI to egress at other Root and Leaf UNIs but to restrict an ingress frame at a Leaf UNI to egress only at Root UNIs. Furthermore, there can be more than one Root UNI in a service. A given Network Element (NE) in a CEN could have more than one Root UNI and/or more than one Leaf UNIs as well has having these on different hardware (e.g., line cards, etc.). Exemplary applications of E-Tree include, without limitation, broadcast/multicast video, IEEE 1588 PTP clock synchronization, mobile backhaul, Internet access, hub and spoke virtual private network, and the like. This implementation is not restricted to only an E-Tree type connectivity and any connectivity across a network that need constrained forwarding between all or subset of the UNIs as service endpoints is applicable.
A conventional implementation of E-Trees is defined in Annex F of IEEE 802.1Q-2011, “Media Access Control (MAC) Bridges and Virtual Bridge Local Area Networks,” using Asymmetric Virtual Local Area Networks (VLANs). A few key aspects of this approach include using different ‘Trunk’ VLANs (hence, asymmetric) to identify traffic ingressing at a Root UNI versus at a Leaf UNI and using additional configurations such as VLAN member sets to restrict the forwarding domain. The Internet Engineering Task Force (IETF) has also ongoing work to support E-Tree across Virtual Private LAN Service (VPLS) networks. There are some disadvantages with this conventional approach such as shared VLAN learning could cause an unknown unicast to be flooded to all UNIs and in-depth port configuration requirements such as VLAN member sets and static VLAN registrations that require additional configurations. Further, not all switch platforms may support asymmetric VLANs. Also, all broadcast/multicast traffic is forwarded through the network, including the leaf to leaf traffic which is dropped by the devices having the egressing UNIs right before they reach the UNIs. Additional complications might also be present in handling of IEEE-802.1Q-2011 Connectivity Fault Management (CFM) frames in these services. That said, with the IEEE 802.1Q-2011, the network bandwidth can be wasted.
Thus, a different approach to support any constrained forwarding based connectivity is desired. In the specific example of an E-Tree service, any such approach must meet the service delivery requirements of E-Tree including port based EP-Tree and VLAN based EVP-Tree, be interoperable with the IEEE 802.1Q-2011 approach, support greater than one Root and/or greater than one Leaf on the same node, and allow a same UNI to be a Root in one E-Tree instance while be a Leaf on another E-Tree instance at that UNI.